-
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
🐛 fix: Nil pointer dereference with Must Bind binding #3171
Conversation
if err is nil err.Error() panics (eg. c.Bind().Must().JSON(...) successfully binds but panics
Thanks for opening this pull request! 🎉 Please check out our contributing guidelines. If you need help or want to chat with us, join us on Discord https://gofiber.io/discord |
WalkthroughThe changes involve updates to the Changes
Possibly related PRs
Suggested labels
Suggested reviewers
📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
@ItsMeSamey Anyway we could trigger this in a new unit-test? |
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #3171 +/- ##
==========================================
- Coverage 82.85% 82.78% -0.08%
==========================================
Files 114 114
Lines 11189 11189
==========================================
- Hits 9271 9263 -8
- Misses 1520 1526 +6
- Partials 398 400 +2
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚨 Try these New Features:
|
make sure returnErr works with nil error
as in majority of cases we expect err to be nil, this should provide better short-cutting
@gaby I've added a test for this |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 1
🧹 Outside diff range and nitpick comments (1)
bind_test.go (1)
22-29
: Approve the new test function with a suggestion.The new
Test_returnErr
function is a good addition to test the fix for the nil pointer dereference issue. It correctly checks that no error is returned when a nil error is passed toreturnErr
.To make the test more robust, consider adding an additional assertion to check the response status code:
err := c.Bind().Must().returnErr(nil) require.Equal(t, nil, err) +require.Equal(t, 200, c.Response().StatusCode())
This will ensure that not only is no error returned, but also that the response status remains unchanged when a nil error is passed.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (2)
- bind.go (1 hunks)
- bind_test.go (1 hunks)
🧰 Additional context used
🔇 Additional comments (2)
bind_test.go (1)
Line range hint
1-1183
: Overall approval of the test file.The
bind_test.go
file appears to be well-structured and comprehensive, covering various binding scenarios including Query, Header, Body, URI, and Cookie bindings. The addition of theTest_returnErr
function complements the existing test suite by addressing the specific issue mentioned in the PR.The file also includes benchmark functions, which are valuable for monitoring performance. No significant issues or necessary improvements are identified in the rest of the file.
bind.go (1)
44-45
: Properly handling nil errors to prevent nil pointer dereferenceThe updated condition
if err == nil || b.should
ensures that the function returns early whenerr
isnil
orb.should
istrue
, preventing a nil pointer dereference when callingerr.Error()
later in the code. This change effectively fixes the panic issue described in the pull request.
@gaby |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (1)
bind.go (1)
43-43
: Update documentation for Custom bindingThe comment "NOTE: Should/Must is still valid for Custom binders" above the
Custom
method is now outdated sinceShould
/Must
methods have been removed.Remove or update the comment to reflect the new error handling approach.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (3)
- bind.go (11 hunks)
- bind_test.go (0 hunks)
- ctx.go (0 hunks)
💤 Files with no reviewable changes (2)
- bind_test.go
- ctx.go
🧰 Additional context used
🔇 Additional comments (3)
bind.go (3)
52-52
: LGTM: Consistent error handling pattern across all binding methodsThe binding methods now follow a consistent and clean pattern:
- Call the appropriate binder
- Return any binding errors directly
- Validate the struct if binding succeeds
This simplification makes the error handling more predictable and allows users to handle status codes according to their needs.
Also applies to: 61-61, 71-71, 80-80, 89-89, 98-98, 107-107, 116-116, 125-125
147-147
: LGTM: Clean error handling in Body bindingThe Body binding method maintains a clean separation of concerns while consistently handling errors from custom binders. The direct error return aligns with the new error handling pattern.
22-22
: Breaking Change: Removal of Must/Should chaining capabilityThe removal of the
should
field from theBind
struct is a breaking change that will affect existing code using theMust()
/Should()
chaining pattern. This change is necessary to fix the nil pointer dereference issue, but requires careful migration planning.Consider documenting the migration path for users in the changelog, suggesting alternative error handling patterns such as:
if err := c.Bind().JSON(&data); err != nil { return err }
we will discuss this again internally and then let you know which way we want to go, thank you for your work and help |
here the last statement we want to rename the feature so that there is no confusion with the golang concept of MUST for panics because the methods always return an error |
Added a requested clarification
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (1)
docs/api/bind.md (1)
461-468
: Improve clarity and fix grammatical error
- Fix the grammatical error: "therefor" should be "therefore"
- Consider adding more details about error handling behavior
### WithAutoHandling If you want to handle binder errors automatically, you can use `WithAutoHandling`. If there's an error, it will return the error and set HTTP status to `400 Bad Request`. -This function does NOT panic therefor you must still return on error explicitly +This function does NOT panic therefore you must still return on error explicitly. It safely handles +all error cases, including nil errors. ```go title="Signature" func (b *Bind) WithAutoHandling() *Bind🧰 Tools
🪛 LanguageTool
[grammar] ~465-~465: Did you mean to write ‘therefore’?
Context: ... Request`. This function does NOT panic therefor you must still return on error explicit...(THEREFORE)
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (1)
docs/api/bind.md
(1 hunks)
🧰 Additional context used
🪛 LanguageTool
docs/api/bind.md
[grammar] ~465-~465: Did you mean to write ‘therefore’?
Context: ... Request`. This function does NOT panic therefor you must still return on error explicit...
(THEREFORE)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (7)
binder/README.md (4)
86-86
: Clarify WithAutoHandlingWithStatus in the documentationThe section title mentions "WithAutoHandlingWithStatus", but this method is not explained or demonstrated in the documentation. Consider either:
- Adding documentation for WithAutoHandlingWithStatus, or
- Removing it from the title if it's not yet implemented
Line range hint
88-102
: Improve documentation clarity and examplesSeveral improvements could enhance the documentation:
- The example uses GET with a request body, which is not a common RESTful practice. Consider using POST instead:
-app.Get("/", func(c fiber.Ctx) error { +app.Post("/", func(c fiber.Ctx) error {
- Add an explicit example of the error response format:
// Error Response Example: // { // "error": "Bad request: name is empty" // }
- Clarify the automatic error handling behavior:
-If there's an error it'll return error and 400 as HTTP status. +If there's a validation error or binding failure, it automatically sets a 400 HTTP status code and returns an error response.
- Document the nil error handling improvement:
// Note: WithAutoHandling safely handles nil errors during binding, // preventing potential panics in the error handling chain.🧰 Tools
🪛 LanguageTool
[uncategorized] ~90-~90: A comma might be missing here.
Context: ...erWithAutoHandling()
. If there's an error it'll return error and 400 as HTTP stat...(AI_EN_LECTOR_MISSING_PUNCTUATION_COMMA)
[uncategorized] ~90-~90: The preposition “of” seems more likely in this position.
Context: ...d 400 as HTTP status. Here's an example for it: ```go // Field names should start ...(AI_EN_LECTOR_REPLACEMENT_PREPOSITION)
102-102
: Consider adding error handling examplesThe example could be enhanced to show different error scenarios and their handling:
// Example 1: Missing required field c.Bind().WithAutoHandling().JSON(p) // Result: 400 Bad Request - "name is empty" // Example 2: Invalid JSON c.Bind().WithAutoHandling().JSON(p) // Result: 400 Bad Request - "invalid JSON format" // Example 3: Successful binding c.Bind().WithAutoHandling().JSON(p) // Result: Continues execution normally
Documentation needs update: WithAutoHandlingWithStatus method doesn't exist
The documentation in
binder/README.md
mentions "WithAutoHandling/WithAutoHandlingWithStatus" in its heading and content, but the codebase only implementsWithAutoHandling()
. The actual implementation shows thatWithAutoHandling()
sets the status code to 400 on error, making the separate "WithStatus" variant unnecessary or removed.
- Remove references to "WithAutoHandlingWithStatus" from the documentation heading and content in
binder/README.md
- The rest of the documented behavior for
WithAutoHandling()
is accurate, including the 400 status code and error handling🔗 Analysis chain
Line range hint
86-102
: Verify documentation consistency with implementationLet's ensure the documentation accurately reflects the implemented method names and behaviors.
Let me gather more specific information about the binding implementation.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify method names and signatures in the codebase # Check for old method names to ensure complete migration echo "Checking for any remaining references to old method names..." rg -i "Must\(\)" --type go rg -i "Should\(\)" --type go # Verify new method signatures echo "Verifying new method signatures..." ast-grep --pattern 'func $_(c *Ctx) Bind() *Bind { $$$ }' # Check for any remaining references to WithAutoHandlingWithStatus echo "Checking WithAutoHandlingWithStatus references..." rg -i "WithAutoHandlingWithStatus"Length of output: 553
Script:
#!/bin/bash # Search for WithAutoHandling implementation and usage echo "Checking WithAutoHandling implementation..." rg -A 5 "WithAutoHandling" # Search for binding-related structs and methods echo "Checking Bind struct and methods..." ast-grep --pattern 'type Bind struct { $$$ }' # Look for actual binding implementation echo "Looking for binding implementation..." ast-grep --pattern 'func (b *Bind) JSON($_) error { $$$ }'Length of output: 4003
🧰 Tools
🪛 LanguageTool
[uncategorized] ~90-~90: A comma might be missing here.
Context: ...erWithAutoHandling()
. If there's an error it'll return error and 400 as HTTP stat...(AI_EN_LECTOR_MISSING_PUNCTUATION_COMMA)
[uncategorized] ~90-~90: The preposition “of” seems more likely in this position.
Context: ...d 400 as HTTP status. Here's an example for it: ```go // Field names should start ...(AI_EN_LECTOR_REPLACEMENT_PREPOSITION)
bind.go (2)
34-41
: Consider enhancing the documentationWhile the rename to
WithAutoHandling
is good, consider making the documentation more explicit about nil error handling to prevent future confusion.- // If you want to handle binder errors automatically, you can use `WithAutoHandling`. - // If there's an error, it will return the error and set HTTP status to `400 Bad Request`. - // You must still return on error explicitly + // WithAutoHandling configures automatic error handling for binding operations. + // When an error occurs: + // 1. Sets HTTP status to 400 Bad Request + // 2. Returns a formatted error message + // When no error occurs (nil error): + // 1. Returns nil without modifying the response + // Note: You must still handle the returned error in your code🧰 Tools
🪛 golangci-lint
34-34: File is not
goimports
-ed(goimports)
34-34: File is not
gofumpt
-ed with-extra
(gofumpt)
66-66
: Fix typo in documentationThere's a typo in the note: "WithAutoHandling/WithAutoHandling" should be "WithAutoHandling/WithoutAutoHandling".
- // NOTE: WithAutoHandling/WithAutoHandling is still valid for Custom binders. + // NOTE: WithAutoHandling/WithoutAutoHandling is still valid for Custom binders.docs/api/bind.md (1)
465-465
: Fix grammar in documentationThere are two grammar issues in this line:
- "therefor" should be "therefore"
- Missing comma before "therefore"
-This function does NOT panic therefor you must still return on error explicitly +This function does NOT panic, therefore you must still return on error explicitly🧰 Tools
🪛 LanguageTool
[uncategorized] ~465-~465: Possible missing comma found.
Context: ...00 Bad Request`. This function does NOT panic therefor you must still return on error...(AI_HYDRA_LEO_MISSING_COMMA)
[grammar] ~465-~465: Did you mean to write ‘therefore’?
Context: ... Request`. This function does NOT panic therefor you must still return on error explicit...(THEREFORE)
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (4)
bind.go
(3 hunks)binder/README.md
(2 hunks)ctx.go
(3 hunks)docs/api/bind.md
(1 hunks)
🧰 Additional context used
🪛 golangci-lint
bind.go
34-34: File is not goimports
-ed
(goimports)
34-34: File is not gofumpt
-ed with -extra
(gofumpt)
ctx.go
1863-1863: File is not gofumpt
-ed with -extra
(gofumpt)
1863-1863: File is not goimports
-ed
(goimports)
🪛 LanguageTool
docs/api/bind.md
[uncategorized] ~465-~465: Possible missing comma found.
Context: ...00 Bad Request`. This function does NOT panic therefor you must still return on error...
(AI_HYDRA_LEO_MISSING_COMMA)
[grammar] ~465-~465: Did you mean to write ‘therefore’?
Context: ... Request`. This function does NOT panic therefor you must still return on error explicit...
(THEREFORE)
🔇 Additional comments (7)
bind.go (5)
22-23
: LGTM! Improved field naming
The rename from should
to dontHandle
better reflects the actual behavior of the flag and aligns with the new method names.
26-32
: LGTM! Clear method naming and documentation
The rename to WithoutAutoHandling
makes the behavior more explicit, and the documentation clearly indicates this is the default behavior.
43-46
: LGTM! Nil error check fixes the reported issue
The condition err == nil || b.dontHandle
correctly handles both nil errors and manual error handling mode.
49-50
: Consider previous security feedback about error exposure
The previous review comment about not exposing internal error details to clients is still valid. Consider implementing that suggestion to improve security.
34-41
: Verify all usages of renamed methods
Let's verify that all usages of the old method names (Must
and Should
) have been updated throughout the codebase.
✅ Verification successful
No issues found with method renaming
The codebase shows that WithAutoHandling()
is correctly used in tests and there are no references to the old method names (Must
and Should
). The changes appear to be properly implemented with no remaining references to the old methods.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for any remaining references to the old method names
echo "Checking for old method names..."
rg -l "\.Must\(\)" --type go
rg -l "\.Should\(\)" --type go
# Search for new method names to confirm updates
echo "Verifying new method names..."
rg -l "\.WithAutoHandling\(\)" --type go
rg -l "\.WithoutAutoHandling\(\)" --type go
Length of output: 309
Script:
#!/bin/bash
# Let's check the actual usage context of these methods
echo "Checking WithAutoHandling usage context:"
rg "\.WithAutoHandling\(\)" -B 2 -A 2 --type go
echo -e "\nChecking test file content for better context:"
cat bind_test.go
Length of output: 47741
🧰 Tools
🪛 golangci-lint
34-34: File is not goimports
-ed
(goimports)
34-34: File is not gofumpt
-ed with -extra
(gofumpt)
docs/api/bind.md (2)
461-477
: Add information about error handling improvements
The documentation should address the nil pointer dereference fix that motivated this change.
Add this explanation:
If you want to handle binder errors automatically, you can use `WithAutoHandling`.
-If there's an error, it will return the error and set HTTP status to `400 Bad Request`.
+If there's an error, it will return the error and set HTTP status to `400 Bad Request`. This method
+safely handles all error cases, including nil errors, preventing potential panics that could occur
+when using error handling methods.
+
+:::note
+This method replaces the previous `Must` method and includes improved error handling to prevent
+nil pointer dereference issues.
+:::
🧰 Tools
🪛 LanguageTool
[uncategorized] ~465-~465: Possible missing comma found.
Context: ...00 Bad Request`. This function does NOT panic therefor you must still return on error...
(AI_HYDRA_LEO_MISSING_COMMA)
[grammar] ~465-~465: Did you mean to write ‘therefore’?
Context: ... Request`. This function does NOT panic therefor you must still return on error explicit...
(THEREFORE)
461-477
: LGTM! Clear documentation for the renamed methods
The documentation clearly explains the purpose and behavior of both WithAutoHandling
and WithoutAutoHandling
methods, maintaining consistency with the code changes.
🧰 Tools
🪛 LanguageTool
[uncategorized] ~465-~465: Possible missing comma found.
Context: ...00 Bad Request`. This function does NOT panic therefor you must still return on error...
(AI_HYDRA_LEO_MISSING_COMMA)
[grammar] ~465-~465: Did you mean to write ‘therefore’?
Context: ... Request`. This function does NOT panic therefor you must still return on error explicit...
(THEREFORE)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (3)
bind.go (2)
34-37
: Enhance documentation for clarityWhile the documentation is good, consider adding examples to illustrate proper usage, especially regarding the note about explicit error returns.
Example addition:
// If you want to handle binder errors automatically, you can use `WithAutoHandling`. // If there's an error, it will return the error and set HTTP status to `400 Bad Request`. // You must still return on error explicitly +// +// Example: +// if err := c.Bind().WithAutoHandling().JSON(&data); err != nil { +// return err // Required: must explicitly return the error +// }🧰 Tools
🪛 golangci-lint (1.61.0)
34-34: File is not
gofumpt
-ed with-extra
(gofumpt)
66-66
: Fix typo in documentationThere's a typo in the comment:
-// NOTE: WithAutoHandling/WithAutoHandling is still valid for Custom binders. +// NOTE: WithAutoHandling/WithoutAutoHandling is still valid for Custom binders.ctx.go (1)
1863-1864
: Field rename looks good, but fix formattingThe rename from
should
todontHandleErrs
improves clarity and aligns with the nil pointer dereference fix. However, there's a minor formatting issue.Fix the extra spaces after the colon:
- ctx : c, - dontHandleErrs: true, + ctx: c, + dontHandleErrs: true,🧰 Tools
🪛 golangci-lint (1.61.0)
1863-1863: File is not
gofumpt
-ed with-extra
(gofumpt)
1863-1863: File is not
goimports
-ed(goimports)
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (2)
bind.go
(3 hunks)ctx.go
(3 hunks)
🧰 Additional context used
🪛 golangci-lint (1.61.0)
bind.go
22-22: File is not goimports
-ed
(goimports)
22-22: File is not gofumpt
-ed with -extra
(gofumpt)
34-34: File is not gofumpt
-ed with -extra
(gofumpt)
ctx.go
1863-1863: File is not gofumpt
-ed with -extra
(gofumpt)
1863-1863: File is not goimports
-ed
(goimports)
🔇 Additional comments (5)
bind.go (4)
22-23
: LGTM: Field rename improves clarity
The rename from should
to dontHandleErrs
better communicates the field's purpose and aligns with the new method names.
🧰 Tools
🪛 golangci-lint (1.61.0)
22-22: File is not goimports
-ed
(goimports)
22-22: File is not gofumpt
-ed with -extra
(gofumpt)
43-46
: LGTM: Proper nil check prevents panic
The nil check before accessing the error properly fixes the nil pointer dereference issue.
49-50
:
Security: Avoid exposing internal error details
The current implementation exposes internal error details to clients, which could leak sensitive information.
Consider implementing a more secure error handling approach:
b.ctx.Status(StatusBadRequest)
-return NewError(StatusBadRequest, "Bad request: "+err.Error())
+// Log the detailed error for debugging
+b.ctx.App().Logger().Error(err)
+// Return a generic error message to the client
+return NewError(StatusBadRequest, "Invalid request format")
28-40
: Verify method rename impact
Let's verify that all call sites have been updated to use the new method names.
✅ Verification successful
Based on the analysis of the shell script results, I can now generate the final response:
Method rename impact verified successfully
The codebase shows proper adoption of the new method names:
WithAutoHandling()
is used in tests and properly tested for error handling- No instances of old method names (
Must()
orShould()
) were found - The new methods are well documented and have proper test coverage
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for any remaining usage of old method names
echo "Checking for old method names..."
rg -l "\.Must\(\)" --type go
rg -l "\.Should\(\)" --type go
# Search for usage of new method names to ensure proper adoption
echo "Checking new method usage..."
rg -l "\.WithAutoHandling\(\)" --type go
rg -l "\.WithoutAutoHandling\(\)" --type go
Length of output: 307
Script:
#!/bin/bash
# Let's check the actual usage context of these methods
echo "Checking WithAutoHandling usage context..."
rg "\.WithAutoHandling\(\)" -B 2 -A 2 --type go
echo "Checking if there are any other similar method patterns in bind.go..."
rg "func.*Bind.*\)" bind.go
# Let's also check test coverage to ensure the new methods are properly tested
echo "Checking test coverage..."
cat bind_test.go
Length of output: 48495
🧰 Tools
🪛 golangci-lint (1.61.0)
34-34: File is not gofumpt
-ed with -extra
(gofumpt)
ctx.go (1)
643-643
: Documentation improvement looks good!
The added comment clarifies that the function is generic and can handle different header types, which improves code maintainability.
Thx |
@ItsMeSamey pls fix the lint errors |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (1)
bind.go (1)
66-66
: Fix typo in documentation.The comment has a duplicate "WithAutoHandling". It should be "WithAutoHandling/WithoutAutoHandling".
-// NOTE: WithAutoHandling/WithAutoHandling is still valid for Custom binders. +// NOTE: WithAutoHandling/WithoutAutoHandling is still valid for Custom binders.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (2)
bind.go
(3 hunks)ctx.go
(3 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- ctx.go
🔇 Additional comments (4)
bind.go (4)
26-41
: LGTM! Method renames improve API clarity.
The renames from Should()
/Must()
to WithoutAutoHandling()
/WithAutoHandling()
are excellent improvements:
- More descriptive of their actual behavior
- Removes confusion with Go's
Must
convention for panics - Clear documentation explaining the purpose
43-51
:
Fix addresses nil pointer but retains security concern.
The nil check at line 45 correctly fixes the nil pointer dereference. However, as noted in the previous review, exposing raw error messages to clients remains a security concern.
Consider this safer implementation:
func (b *Bind) returnErr(err error) error {
if err == nil || b.dontHandleErrs {
return err
}
b.ctx.Status(StatusBadRequest)
- return NewError(StatusBadRequest, "Bad request: "+err.Error())
+ b.ctx.App().Logger().Error(err)
+ return NewError(StatusBadRequest, "Invalid request format")
}
28-38
: Verify migration of existing code.
Since this is a breaking change that renames public methods, we should verify that all existing code has been updated.
✅ Verification successful
Let me check the actual content of these files to see if they contain the old method names or just the words "Must" or "Should" in different contexts.
Breaking changes have been properly migrated
The verification shows that:
- No instances of the old method names
.Must()
or.Should()
exist in the codebase - The new methods
WithAutoHandling
andWithoutAutoHandling
are properly documented and used consistently in:- Main implementation (
bind.go
) - Tests (
bind_test.go
) - Documentation (
docs/api/bind.md
,binder/README.md
)
- Main implementation (
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for any remaining references to old method names
echo "Checking for old method names..."
rg -i "\.Must\(\)" || echo "No .Must() calls found"
rg -i "\.Should\(\)" || echo "No .Should() calls found"
# Search for examples and tests that might need updating
echo "Checking for potential test files..."
fd -e test.go | xargs rg -l "Must|Should"
Length of output: 601
Script:
#!/bin/bash
# Check the actual content of files that matched
echo "Checking content of matched files..."
for file in app_test.go ctx.go path.go middleware/rewrite/rewrite.go middleware/redirect/redirect.go middleware/adaptor/adaptor_test.go ctx_test.go client/request_test.go binder/mapping.go client/hooks.go; do
if [ -f "$file" ]; then
echo "=== $file ==="
rg -C 2 "\.Must\(\)|\.Should\(\)" "$file" || echo "No exact method calls found"
fi
done
# Also check for any WithoutAutoHandling or WithAutoHandling usage
echo -e "\nChecking for new method usage..."
rg "WithoutAutoHandling|WithAutoHandling"
Length of output: 5845
22-23
: LGTM! Field rename improves clarity.
The rename from should
to dontHandleErrs
better describes the field's purpose. However, since this inverts the boolean logic, we should verify all usages.
✅ Verification successful
Field rename improves clarity and maintains correct error handling logic
The rename from should
to dontHandleErrs
is verified to be correctly implemented. The field is used consistently throughout the codebase:
WithoutAutoHandling()
sets it totrue
(default behavior)WithAutoHandling()
sets it tofalse
returnErr()
method correctly checksif err == nil || b.dontHandleErrs
to determine whether to return raw error or handle it with 400 status
The boolean logic is properly inverted and all usages are consistent with the new name's semantics.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Verify all usages of the new field name and ensure correct boolean logic
ast-grep --pattern 'dontHandleErrs'
Length of output: 72
Script:
#!/bin/bash
# Let's check the usage context of dontHandleErrs more thoroughly
rg "dontHandleErrs" -B 3 -A 3
# Also check for the old field name 'should' to compare the logic
rg "should" -B 3 -A 3 --type go
# Let's also see the full Bind struct definition
ast-grep --pattern 'type Bind struct {
$$$
}'
Length of output: 95306
Script:
#!/bin/bash
# Let's check the methods that use dontHandleErrs to verify the logic
ast-grep --pattern 'func ($b *Bind) $$$() $$ {
$$$
dontHandleErrs
$$$
}'
# Also check for any error handling related methods
rg "returnErr" -A 5 -B 5
Length of output: 4980
@gaby |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍 LGTM
@ReneWerner87 @efectn Please check my changes to the README.md, if all good then we can merge it. |
Congrats on merging your first pull request! 🎉 We here at Fiber are proud of you! If you need help or want to chat with us, join us on Discord https://gofiber.io/discord |
if err is nil err.Error() panics
(eg. c.Bind().Must().JSON(...) successfully binds but panics